1. Field of the Invention
This invention relates to the field of computer applications, and, more specifically, to object-oriented client-server applications.
Sun, Sun Microsystems, the Sun logo, Java, Java 3D and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks of SPARC International, Inc. in the United States and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc.
2. Background Art
In monolithically designed object-oriented computer applications, program code is developed as a collection of objects linked as an “object web.” Each object encapsulates its own data, as well as methods for operating on that data. In the execution of the application, messages are sent between objects, calling the various methods to implement the application. However, more and more frequently, applications are being designed as distributed in nature. That is, elements of the application may exist in separate execution environments, sometimes resident within the same computer system, but more often executed in multiple computer systems coupled via a network. An example of such a distributed scheme is the client-server paradigm. Unfortunately, as described below, it is difficult for monolithic distributed applications to provide efficient communication between the distributed elements of the application.
In a client-server application, the functionality of the application is split between two primary locations, i.e., the “client” and the “server.” In many cases, the same server will interface with multiple clients, e.g., for common access to a database or shared services. In this type of environment, for a monolithically designed application, communication is generalized into simple client-server messages transmitted over a common communication channel.
Typically, one communication object or component of the client receives all outgoing message requests from the application objects local to the client. Those outgoing message requests are packaged (e.g., as a network packet) and sent via the common channel to the server. At the server, another communication object receives the packaged message. The communication object, or other server resident object, must then determine what the message is regarding (i.e., what is the message context) and which object on the server should handle the message. It is possible that the message will be processed in this manner by multiple objects before being forwarded to the desired target object on the server. The same communication procedure is repeated over the common communication channel for communications originating from the server for processing by the client.
The process of determining the message context and identifying the appropriate target object can be non-trivial, particularly for large applications. Because the application is monolithic in nature, it may not be obvious which object should handle a message having a particular context. Extra effort may be needed to predetermine what sort of message contexts each object can handle, and organize this predetermined information into a useful format. The application structure must then remain fixed in order for this predetermined information to remain valid. Constraining the application to a static configuration in this way undesirably eliminates any dynamic flexibility in the application, making improvements and alterations to the application more complicated. Efforts are thus needed to improve the efficiency of communication in distributed applications without constraining the flexibility of those applications.
Improving communication in distributed applications require a complex operating architecture and creates a challenge for the designer by requiring development of server side objects and, possibly, multiple client side objects for different clients communicating with the same server side object. Thus, a method is needed to improve design of architectures for distributed applications.
Efforts in the organization of applications include the development of hierarchical tools referred to as “scenegraphs,” which are used to organize rendering applications as directed acyclic graphs. A description of scenegraph techniques is provided below.
Scenegraph Techniques
A scenegraph is a tree structure comprising a multiplicity of nodes interconnected in a hierarchical manner. This hierarchical structure provides a well-organized framework for software applications, and one in which functionality may be easily augmented through the addition of one or more nodes to an existing scenegraph. Individual functional application elements are constructed as separate node objects and connected together in a treelike structure. Those node objects are then manipulated using their predefined accessor, mutator and node-linking methods.
For reference, an object is a programming unit that groups together a data structure (one or more instance variables) and the operations (methods) that can use or affect that data. Thus, an object consists of data and one or more operations or procedures that can be performed on that data. An object can be instructed to perform one of its methods when it receives a “message.” A message is a command or instruction sent to the object to execute a certain method. A message consists of a method selection (e.g., method name) and zero or more arguments. A message tells the receiving object what operations to perform.
Any given object is an “instance” of a particular class. A class provides a definition for an object which typically includes both fields (e.g., variables) and methods. (The term “object” by itself is often used interchangeably to refer to a particular class or a particular instance.) An instance of a class includes the variables and methods defined for that class. Multiple instances can be created from the same class.
In the construction of a scenegraph, a child node object is attached to a parent group node object by calling the “addChild” method of the parent node object and specifying the child node object in the input field. A reference to the child node object is then stored in the parent node object, enabling general scenegraph mechanisms, such as traversal methods, to be implemented between the parent and child node objects. Other specific mechanisms for linking child nodes may be implemented for specific node object types. Also, constraints may be placed on what types of node objects may be linked as children to other specific node types to enforce particular nodal relationships of scenegraph implementations.
Scenegraphs are currently used in graphics rendering applications. The scenegraph contains a complete description of the entire scene, or virtual universe. This includes the geometric data, the attribute information, and the viewing information needed to render the scene from a particular point of view. In the case of a 3D scene, the scenegraph hierarchy promotes a spatial grouping of geometric objects found at the leaves (i.e., end nodes) of the scenegraph. Internal nodes act to group their children together. A group node may also define a spatial bound that contains all the geometry defined by its descendants. Spatial grouping allows for efficient implementation of operations such as proximity detection, collision detection, view frustrum culling and occlusion culling.
Node objects of a scenegraph may be separated into “group node” objects and “leaf node” objects. Group node objects group together one or more child nodes, and can be used to define behavior or relationships common to those child nodes. A leaf node has no children and only one parent. The state of a leaf node includes any state in a direct path between the leaf node and the source or “root” node of the scenegraph. In the context of a graphics scene, leaf node objects contain the actual definitions of shapes (geometry), lights, fog, sound, etc. When a scene is rendered, the renderer incorporates all state changes made in a direct path from the root node of the scenegraph to a leaf node object in the drawing of that leaf node object.
FIG. 1 illustrates a general scenegraph structure used to represent a 3D scene in accordance, for example, with scenegraph policies as described in the Java 3D™ API Specification available from Sun Microsystems, Inc. The scenegraph of FIG. 1 comprises a single root node, referred to as virtual universe (VU) 100, one or more locale nodes (LO) 101, one or more branch group nodes (BG) 102, one or more group nodes (GN) 103, and one or more leaf nodes (LN) 104.
Virtual universe 100 represents the center of the scene, with all child nodes being positioned relative to it. One or more high-resolution locale nodes 101 are coupled to virtual universe 100. Each such locale node 101 specifies a relative offset position with respect to virtual universe 100. This relative offset is represented in a high-resolution format to accommodate distance relationships comparable to the smallest and largest conceived distances in the real world. Each locale node 101 may be used to attach one or more branch group nodes 102, whose rendering positions are interpreted relative to the given locale node 101.
Branch group nodes 102 generally act as a root node of a subgraph associated with the given parent locale node 101. When a branch group node 102 is attached to a locale node 101, and hence to a virtual universe 100, the branch group node and its descendants are considered “live” (i.e., ready to render) with respect to the scene. One or more general group nodes 103 may be attached as child nodes to each branch group node 102. Each group node 103 may support zero or more child nodes in the form of further group nodes 103 or leaf nodes 104.
An example of an implementation of a group node 103 is as a transform node that contains a transform matrix used to scale, rotate, and position its descendants. Other group nodes implemented as “behavior” nodes may be used to embody algorithms for modifying the transform matrices of specified transform objects. Certain leaf node objects may also have references to component objects (not shown) which specify specific attributes of the given leaf node object (e.g., a shape leaf node may have as associated component objects a geometry component object, specifying a geometric shape of the shape leaf node, and an appearance component object, specifying the appearance of the shape in terms of color, texture, etc.). One leaf node is typically used to represent the viewing platform for rendering purposes, with associated component objects for specifying attributes of the rendering viewpoint, as well as the canvas or screen on which the rendered output is to be displayed.